.dmg/Shareware World/Comms & Internet/AutoShare2.0/Documentation/HTML/images/new-yellow.GIF)
.dmg/Shareware World/Comms & Internet/AutoShare2.0/Documentation/HTML/images/autoshare.GIF)
Getting started
Running the server
.dmg/Shareware World/Comms & Internet/AutoShare2.0/Documentation/HTML/images/triblue.GIF)
What are EIMS and SIMS?
With the release of version 1.2.1,
SIMS (Stalker Internet Mail Server) too
may be used with AutoShare. Click
here for instructions.
What is AutoShare?Are you ready for AutoShare? The highly configurable feature cornucopiua puts the sizzle in this razzle-dazzle extravaganza. AutoShare is truly the house of generosity when it comes to features and functionality. And yet at the same time, AutoShare is a jumping jackpot racing to do its thing without asking for much memory, even when your lists has tens of thousands of subscribers. AutoShare is the fun town that never sleeps!
Using AutoShare for the first timeWhen configuring your EIMS accounts and your AutoShare preferences, always test your configuration first before letting your subscribers do it.
Before setting up your first list server list, decide whether subscriber addresses should be based on the RFC From address (where to reply to) or the SMTP envelope sender (where it is coming from) of the subscription requests; if the former, then configure accordingly.
Upgrading AutoShareWhen upgrading to version 2.0, notice that the AutoShare Temp folder has been moved into the AutoShare folder inside Preferences folder; you may go ahead and delete the Temp folder at its former location in the Preferences folder.
Version 2.0 also updates the AppleScript dictionary by adding the Suppress Command, Listserver Label and Locking properties to the Misc Options. A new AppleScript property in the Stat Options is LockingFiles. New optional AppleScript parameters in the Send Mail command are File Quote and File Delete. New AppleScript commands used with multiple preferences sets are SetPreference, GetPreference and GetPreferences. Furthermore, the SetKeepUp, GetKeepUp and GetCreatorApp commands make the Keep applications up feature completely scriptable.
If you are using EIMS 2.0, please notice that the Mail Folder has been moved inside the EIMS 2.0 application folder, which means that you must reconfigure your Incoming Mail folder in AutoShare.
When upgrading to version 1.4, be aware that new file extensions (.text and .txt) have been assigned to digests and text archives.
Version 1.4 also updates the AppleScript dictionary in a number of ways. The Quote property in List Options has been changed from a boolean value to a number (indicating a percentage). New List Options properties are RFC Headers, List Stuff, Address Protection, Tip Of The Day, Approval Both and Hard Unsubscribe. All boolean types in List Options have changed to non-boolean types to accommodate the default/override values. New Misc Options properties are Line Format, Keep Up, Processing, Status Window Position, Hide Window (formerly a command!) and Misc Stuff.
EIMS and AutoShareAutoShare supports EIMS as the mail server sending and receiving mail, and transactions between the two servers are based on the use of fast file transactions rather than the use of mail protocols. The basic flow is that EIMS stores received message files in a Filed Mail folder for AutoShare and that AutoShare processes the message files and puts them as outgoing mail in the Incoming Mail folder for EIMS.
.dmg/Shareware World/Comms & Internet/AutoShare2.0/Documentation/HTML/autoshare/samples/Images/FiledAndIncoming.GIF/FiledAndIncoming.GIF)
In order to use AutoShare, a thorough knowledge of the EIMS account types is required (EIMS documentation is available here):
What is a list server?You may have heard of complex Unix software with specific names such as LISTSERV, Majordomo or ListProc (to obtain the Mailing List Management (MLM) software FAQ, write 'get mlm-software faq' in the body of mail to listserv@listserv.net). You may be aware of commercial Macintosh list server software such as StarNine's ListSTAR (formerly eMOD) as well, which was released June 26 1995.
The list server feature has been developed as a natural extension within AutoShare and of EIMS. The list server account is merely an auto-response account with a number of special features added to it; the list server lists are set up using separate EIMS accounts (although not possible here, integrating the list server features into the list account itself would lead to far too dangerous events: imagine you wanted to unsubscribe from a list, but misspelled the command, then everyone on the list would receive the message!).
Auto-responsesEach auto-response service may optionally include a BinHex enclosure.
Vacation notices System requirements Applications Folders
AutoShare (or similar) = folder with AutoShare server application Filed Mail (or similar) = EIMS, Saved as files folder Incoming Mail = EIMS, Incoming Mail folder Documents (or similar) = folder with user named subfolders with text files List Server (or similar) = folder with list server mailing lists Archives (or similar) = folder with archive files Filters (or similar) = folder with filter files AutoShare = folder storing preferences, logs and more AutoShare Temp = folder storing outgoing mail until completedThe last two folders reside inside the System 7 savvy Preferences folder.
The illustration below puts the folders in perspective.
.dmg/Shareware World/Comms & Internet/AutoShare2.0/Documentation/HTML/autoshare/samples/Images/AllFolders.GIF/AllFolders.GIF)
When doing the initial configuration (see also the quick tutorial below), it is recommended that you start out creating a folder, e.g. Auto, inside the harddisk root folder for your AutoShare folders. Then create the Filed Mail folder (and other folders) inside the Auto folder. As for EIMS, the Saved as files accounts must specify the Filed Mail folder.
Files
AutoShare = server application Default etc = list server and auto-response documents Default.hqx etc = Binhex 4.0 enclosures for auto-responses Subscriber list files = EIMS mailing lists in list server folder Archive files = list server list archives Filter files = filter documents AutoShare Preferences = preferences file AutoShare Log = log fileIn the Documents folder (e.g. inside the Auto folder), user subfolders should be created, one per account; the following documents are likely to reside within each subfolder:
An introductory tour The folders on your server Configuring AutoShare and EIMS
.dmg/Shareware World/Comms & Internet/AutoShare2.0/Documentation/HTML/autoshare/samples/Images/SaveAsFiles.GIF/SaveAsFiles.GIF)
.dmg/Shareware World/Comms & Internet/AutoShare2.0/Documentation/HTML/autoshare/samples/Images/MailingList.GIF/MailingList.GIF)
To create another list service, AutoShare requires you to create a list document (named after the service) in the List Server folder, and EIMS requires you to create one account configured as Save As Files and two accounts configured as Mailing List.
The following illustration shows AutoShare interacts with all of its standard folders (not including folders for the software, the documentation or the preferences).
When a request for an auto-response is processed, the document in question is fetched from the Documents folder, and before the auto-response file is created, the filter file in question is checked in the Filters folder. Commands to the list server also use the list files in the List Server folder, and list contributions furthermore update the digest and archive files in the Archives folder.
Testing AutoShare as a user AutoShare server applicationEnter the addresses for the administrator and bounce accounts first. When people send personal mails to the administrator, they use the administrator address. Mail to the bounce address, often error messages, on the other hand is originated by your or other servers (the domain of the bounce account must indicate the domain of your server!).
The other basic settings are Log, Format and Commands. The log setting determines how detailed your logs should be (Brief is fine for most purposes). The format setting indicates whether your archives should be formatted as text and/or HTML. The commands setting decides where AutoShare is looking for list server commands in subscriber mails (Body is recommended).
.dmg/Shareware World/Comms & Internet/AutoShare2.0/Documentation/HTML/images/redarrow.GIF/redarrow.GIF)
Bounce account LogsYou may configure AutoShare for various amounts of log information:
Off = no logging
Always = important messages that are always logged (unless Off)
Brief = a single line per transaction
Tech = detailed information per transaction
Logs are automatically being mailed to the AutoShare administrator and
initialized at scheduled times configured in the Times dialog box (from the Preferences menu, choose the Times menu item). The scheduled times for the digests are configured in the dialog box as well; choose digests from the pop-up menu at the top.You may schedule the times for a particular interval of days and within the day a specific time. If either every <number> days or at <time> has changed and you press the OK button, the new settings take effect immediately; you may update the settings for both logs and digests with a combined single OK.
If the settings have just been updated, every <number> days implies that the first log or digest will be mailed in <number> of days (if set for 1 day, then tomorrow). If you want it to happen later the same day of the configuration, click at that time in the Now checkbox without altering any other settings; you may use the Now checkbox whenever you need more frequently mailed logs or digests in a temporary situation.
The primary transaction information listed as single lines (formatted as a series of transaction information tokens using space delimiters) in the logs applies to the following transaction types (the tokens are listed after the colon):
AutoShare Admin applicationThe AutoShare Admin(istrator) offers a visual interface allowing you complete configuration of AutoShare. The AutoShare Admin communicates, locally or remotely, with the AutoShare server application by acting as a client sending AppleEvents. The Admin behaves very gentleman-like and for instance does not update the AutoShare Preferences file directly, but rather asks the AutoShare server application to do it. The sole role of the AutoShare Admin is the configuration of the AutoShare server by sending events to it, even if the two applications run on the same Mac.
The Admin is written using FaceSpan version 2.1 and includes many scripts taking full advantage of the scripting dictionary of AutoShare. It is FAT, thereby being native to both 68K and PowerPC, and comes as a Miniature application, which means that the FaceSpan Extension must reside in the System 7 Extensions folder for the Admin to work.
The FaceSpan Extension is expecting to find the QuickTime and QuickTime PowerPlug extensions in the system before it can be resolved. Both of these extensions are part of a standard MacOS install. If you are experiencing such problems using the AutoShare Admin, it is more than likely they have been turned off via the Extensions Manager.
The AutoShare Admin may be used on any Mac on the same AppleTalk network that the Mac running AutoShare is located on. Please read about the AutoShare scriptability for configuration of Program Linking. When using the Admin remotely, be sure to put a copy of the AutoShare application on the Mac (preferably in the same folder as the Admin) on which you are using the Admin, so that the AutoShare AppleScript dictionary can be read by the Admin. Or you may use the ResEdit file entitled AutoShare (must reside in the Admin folder), which contains the AutoShare AppleScript dictionary only.
Balloon help, serving as brief reminders of the documentation that you are reading here, has been added to all windows, so that you may instantly read about the various fields of these windows. Further details on configuration are available in the section describing the AutoShare Preferences and list-specific configuration.
As the user interface of the Admin forms a complete and well-structured version of the basic user interface of the server application, no manual on the Admin is available per se. Simply keep in mind that the Miscellaneous and Lists windows are the key to the AutoShare configuration.
Menu selectionsFile menu: (N = New) (O = Open) (W = Close) (S = Save) (P = Print) Q = Quit Edit menu: Z = Undo X = Cut C = Copy V = Paste (A = Select All) Preferences menu: M: Miscellaneous J = More Miscellaneous F = Folders K = More Folders T = Times U = Multiple Preferences Configuration menu: E = Where L = Lists D = Documents I = Filters H = Hosts Y = Keep Applications Up Extras menu: (no letters used) (B, G, R are not used)
AutoShare scriptabilityApple Events scripting using AppleScript is perhaps the most important addition to System 7. This was enhanced in System 7.5 by introducing the scriptable Finder. AutoShare is fully scriptable, allowing you a convenient way of remote configuration. If you haven't tried using AppleScript, please locate the part of your System software that includes the files such as the Script Editor.
Once you have completed the installation of the Apple Events system software, you may want to look into features like Program Linking, which enables you to control scriptable software from another Mac on the same AppleTalk network, even if you have access to the network via AppleTalk Remote Access (ARA). Program Linking is configured this way.
A number of AppleScript commands, SetRes, GetRes, Analysis, Subscribe, Unsubscribe, GetSubscriber, GetSubscribers, SetList, GetList, GetLists, SetMisc, GetMisc, SetFolders, GetFolders, SetTimes, GetTimes, SetHosts, GetHosts, SetKeepUp, GetKeepUp, GetCreatorApp, SetFilters, GetFilters, Review, Write Log, GetStat, File Mail, Send Mail, SetPreference, GetPreference and GetPreferences, have been added to AutoShare's support for scripting. The required commands, Run and Quit, are of course still supported. Furthermore, a single AppleScript script can perform several changes.
On the topic of errors, it is important to distinguish between actual AppleScript errors (most often unlikely) and a given AutoShare request not being successful (likely to happen from to time). When issuing for instance the GetSubscriber command, no result will be returned, if an AppleScript error, e.g. when fetching a property, occurs. On the other hand, an empty result will be returned, if there are no AppleScript errors, but, say, the subscriber could not be found. Your AppleScript scripting should take these kinds of situations into consideration.
AppleScript commands
.dmg/Shareware World/Comms & Internet/AutoShare2.0/Documentation/HTML/images/greenball.GIF)
The two AppleScript commands, SetRes and GetRes, set and get STR# resources in the AutoShare Preferences file. The feature is aimed at users who prefer not to use ResEdit (for the few times that is needed).
Another three AppleScript commands, Analysis (generate an Analysis file), Subscribe (subscribe a user) and Unsubscribe (unsubscribe a user), have been added, as they may come in handy for remote
configuration using Program Linking.
The Unsubscribe command supports the list being all, so all lists are processed.
The AppleScript command, SetList is aimed at configuring the list-specific settings.
When the List property is not used, the remaining properties are directed towards the general list settings.
The AppleScript commands, SetMisc, SetFolders, SetTimes and SetHosts, are directed towards the configuration also accessible via the AutoShare server user interface. The AppleScript syntax is much like that of SetList:
The AppleScript command, Review, enables a subscriber list to be mailed to the main listmaster or a specificed e-mail address. Write Log enables you to send and insert a string into the log. GetStat returns various status information. File Mail lets you create a message file in the Filed Mail folder, as if a sender sent a command to the list server, and Send Mail is a scriptable way of sending your own mail .The Review command supports the list being all, so all lists are processed.
Since the list server account is also an auto-response account, remember to create an autoshare subfolder inside the Documents folder. Inside the autoshare subfolder, create the Default document as well as documents for all list server request commands, each getting its file name from the command. Each document (except the Default document) should include a token for the respective command (e.g. /=LIST for the LIST command), while the rest of the text contents is up to you.
List server list archives, formatted as text and/or HTML, are created automatically. A set of archive files (e.g. Current.text and Current.txt), located in a subfolder (named after the list) inside the Archives folder, will accumulate continuously. Digest files accumulate temporarily.
Whenever a list contribution takes place, the set of digest files (Digest.text and Digest.txt) and the set archive of files (e.g. Current.text and Current.txt) are updated: the message and toc (table of contents) parts are formatted and then appended to the respective files. With the GET command, further formatting is added to form a single text or HTML document (within the begin/end block of the returned message following the GET request).
The list server commands in subscriber mails appear in special command lines (either the subject or the first line(s) of the body), which trigger certain events. Other commands, e.g. including HELP, can be made available as well of course.
List server and list basics List server commands
LIST
REVIEW <list> SUB <list> [<name>]
UNSUB <list> SET <list> <option> INDEX <list> GET <list> <file> WHICH
RELEASE
QUERY <list> SEARCH <list> <string>
Several alias commands are available as well:
SUB: subscribe
UNSUB: unsubscribe, signoff
LIST: lists
REVIEW: rev, recipients, who
INDEX: ind
GET: send
All may be used for the Unsub, Query, Set, Index, Get, Review and Search commands to apply the command to all subscribed lists, e.g. query all.There is no HELP command, but it is surely okay to create a document called HELP.
If your list server has been configured to accept command requests in the body, the subscriber may include several such requests in one and the same mail. When 1. a body line is found which does not begin with a valid command, or 2. there are no more body lines, AutoShare will stop processing the mail.
sub fun-l Mikael Hansen set fun-l ack set fun-l conceal query fun-l review fun-l blah blah listIn the above example, the first five command lines will be processed and returned as five separate mails; the sixth line is not valid (and will generate no response mail), and so the processing halts.
Subscriber list files and formatEach subscriber takes up a separate line within a list file.
0: concealed (if visible, then no 0)
1: digest (if messages, then no 1)
2: no mail (if mail, then no 2)
3: acknowledgement (if not, then no 3)
4: not allowed to post (if post, then no 4)
Examples:
meh@dnai.com (Mikael Hansen)
meh@dnai.com
meh@dnai.com (Mikael Hansen..0)
meh@dnai.com (..0)
meh@dnai.com (Mikael Hansen..012)
meh@dnai.com (..01234)
The codes 5 and upwards are not used.
Searching and sorting subscriber listsThe change is that AutoShare now offers binary searches of the line-based subscriber lists, so that a search for a given address is completed much faster than before. This is in part accomplished by verifying at start-up that the lists are sorted, and when not, sort them using a QuickSort algorithm.
The searching, sorting and insertions for lists are configured using the List Sort property in the Options (Misc); the new status will be saved to the disk settings immediately, but will not become active until the Run command has been issued or AutoShare is restarted. The property may be set to Domain, User or Unsorted; when configured as the latter, AutoShare will not check for lists being ordered when starting up and will apply a simple linear search when looking up subscribers; new subscribers will in this case be appended to the end of the list file.
When sorting, the AutoShare application heap memory is utilized as tightly as possible. Each subscriber takes up 4 bytes plus the number of characters in the address line in question. With an average subscriber string length of 36 characters, a list file of 1,000 subscribers requires around 40K at the time of sorting. It may be noted that if you stick with the same configuration from day one, no sorting will ever have to be applied as new subscribers are placed in their proper location from the very beginning, always leaving the list file sorted.
When subscriber records are added (sub), replaced (set) or deleted (unsub) for a ordered list, an efficient file processing technique optimizes the speed dramatically. Even huge list files will require little time to stay fully updated at all times.
The message and digest list filesEIMS supports the SMTP EXPN command, which is an optional part of RFC 821. This allows anyone to telnet to your server on port 25 and 'expand' an EIMS mailing list to the full list of addresses. If you don't want the names of your subscribers accessible to the public this way, you can enter an alternate name for the EIMS .m and .d accounts in the Work Lists field of AutoShare Admin's List window. Someone could still telnet to your server, but unless they can guess the account name you supply, they won't be able to EXPN your list. For example, you could enter xyzzy in the work lists field. In EIMS, name your accounts xyzzy.m and xyzzy.d. In the field at the bottom of the EIMS account setup window, where you give the path to the mail list file, use the same path you normally would. In other words, if your list is called Fun-L, you'd continue to use Fun-L.m and Fun-L.d as the names of the actual lists, since using the Work Lists field has no effect on those names. Work Lists merely gives an alternate name for the EIMS accounts that point to the mail list files.
List server documents and tokensThe contents of a list server command document is mostly text that you decide on your own how to reflect the context of the command. Standard list server documents also include at least one token line to trigger a given action. Each token pair (a switch and a command) comes without any delimiter.
Standard tokens:
/=original = picks up the original messageCommand tokens:
/=list = displays the lists
/=review = lists the subscribers for a given list
/=sub = confirms the subscription of the user
/=unsub = confirms the cancelled subscription
/=set = updates various options:
conceal: conceals the subscriber (review)
nonconceal: makes the subscriber visible
digest: one daily mail with all list messages
nodigest: individual mail messages
mail: you receive list mail
nomail: subscribed, but no mail
ack: you receive a list contribution copy
noack: no acknowledgment contribution copy
post: allowed to post (admin only)
nopost: cannot post (admin only)
/=index = lists the archive files for a list
/=get = returns a list archive file
/=which = informs you of the lists you are on
/=release = information about the list server software
/=query = information about your subscription status
Token lines are placed in documents at appropriate locations depending on the text contents. While the /=original token can be placed in any document, command-specific tokens should only be added to respective command documents.
List-specific documentsAll of the list server documents may be made list-specific by replacing the document with a folder having the same name and including documents inside this folder with names of "Default" or the list. This also applies to both standard documents for commands without a list parameter and non-standard documents such as Help and Info, as long as the list name is specified as the only parameter.
List typesWhen a contribution is sent to a moderated list, it gets redirected to the listmaster, who may choose to post it or not; if the moderator uses Eudora, the Redirect (or Redirect To) is recommended when posting other people's contributions. When a contribution is sent to an announcement list, the contribution is returned to the sender. In both cases, only the listmaster is able to post to the list. The listmaster address is fetched from the administrator address (from the Preferences menu, choose Miscellaneous).
It may be added that the list-specific configuration enables list-based defaults for the subscription Options. If you prefer subscribers to for instance receive copies of their own contributions without any separate update of the subscriber's options, this is the way to go.
Posting privilegies may be turned on or off for individual subscribers (subscription, open and private lists). The post and nopost tokens may be applied as any other SET option, but with one important restriction: the subscriber cannot successfully use the two new tokens as a valid option within a SET command. They are administrative tokens only (whose option code is '4') to be used by the administrator (scripting commands, remote administration by e-mail or direct editing of main list files).
Tip of the day lists Subscriber addressesAutoShare has historically used the envelope sender, not the RFC From field, to determine the address of a list subscriber, as the envelope sender is generally considered to be the real address, although not visible when viewing the mail message. The SMTP envelope sender is where the mail actually came from, while the RFC From address is where a reply should go to. This definition of the RFC From address is however aimed less at server replies (e.g. EIMS) than at client replies (e.g. Eudora), as POP-based e-mail software (and POP-based list server software too!) cannot download the SMTP envelope and so has no choice (unlike e.g. SMTP-based or file-based list server software, which has access to the SMTP envelope information needed).
If you would like new subscriber addresses to be extracted from the RFC From field, you may use the RFC From property in the AppleScript Options (Misc) to enable this. This means that the list files will contain the RFC From addresses for new subscribers, which will be used whenever a list server request or a list contribution takes a place. The envelope recipient of a list server request to be returned will furthermore be updated to the address in the RFC To field.
Subscriber address protectionUsing address protection prevents the action of harvesting e-mail addresses for unauthorized purposes.
When a subscribe command takes place, the list-specific index file in the Protected Addresses folder inside the AutoShare folder of the System 7 savvy Preferences folder is updated (entry is added). Same for an unsubscribe command (entry is removed). When a review command is issued, the e-mail addresses are replaced by corresponding address tokens.
When a subscriber posts, nothing is initially different. But when the list server receives the list contribution, the RFC From field body is replaced with a special address token, and all RFC X-Sender fields are removed. It is important that the body of your list contribution does not display your e-mail address.
When the subscriber would like to e-mail another subscriber off the list, the mail, with '<list>space<address token>' placed in the subject, is sent to the 'protected@<domain>' e-mail account, which redirects the mail to the recipient.
The envelope recipient gets updated, and the mail message is moved to the Incoming mail folder. If there is no match for the envelope recipient in the index file, the mail is returned to sender.
When sending an initial mail this way, it is encouraged that you be brief and merely state the purpose of your initiative, so that the communication may switch to the direct use of actual e-mail addresses on both sides. It is not intended that the server be allowed access to the contents of your mails more than necessary.
The address protection feature is enabled in AppleScript by the Address Protection property in List Options; the Admin, see the More List window.
We now move onto the issue of what is entitled spam, a term generally used loosely for various abuse of e-mail. You may think of spam as junk mail of many flavors.
It is next to impossible for a computer to figure out if a given mail is abusive, as the contents isn't reviewed in a meaningful fashion. Several steps may be taken though: 1. applying address protection prevents the spammer from harvesting e-mail addresses, 2. spam mails are often lengthy, and limiting the number of lines for list contribution bodies often helps, 3. writing a Before Processing process extender, which parses the mail for various words and optionally deletes the message file before it gets processed, and 4. using mail-back confirmation requires an additional effort from the spammer, who often prefers to move onto another easier target.
Subscriber aliasesThe format per entry is alias address, so if the subscriber addresses are envelope sender based, the RFC From address becomes the alias, and if the subscriber addresses are RFC From based, the envelope sender address becomes the alias.
When an unsubscribe request (standard message files only) takes place and the address isn't found in the main list file, the address will then serve as an alias and be looked up in the index file, and if the corresponding address is present in the list file, this address will be unsubscribed.
To make this feature active, you may use the Subscriber Aliases property in the AppleScript Options (Misc).
List-specific logs Archives and digestsA digest is a text formatted collection of list contribution messages, mailed to digest subscribers often every day at a given time, and the digest file is then emptied on the server, thereby being ready for a new day.
A list archive carries a quite different rhythm in time. In order to prevent an extraordinarily large number of archives, they are generally rolled over after a substantially longer time has elapsed. The archive roll-over, which may be triggered by perhaps 100 list contributions, does not delete, but instead renames the archive file in question, so that it may later be accessed via the Index and Get list server commands.
AutoShare offers both text formatted and HTML formatted list archives. The feature of the fully automated web archives takes it all the way. Once initially configured, the listmaster can sit back and relax, knowing that the continuous stream of incoming list contributions is reliably turned into an at all times fully updated hierarchy on the web server, which may be accessed by the subscriber directly across the Internet using a web browser.
Text and/or HTML archivesIt is strongly recommended that you update all current files in your Archives folder to reflect the new convention!
You may choose both text and HTML formatted archives (rather than just one or the other). Having chosen this option (in the AutoShare application or using AppleScript; the Admin, see the List window), both text and HTML formatted archive files are created if necessary and updated when a list contribution is processed. The Index command will list both .text and .html file names. The Get command will format according to the file extension. The Search command will search both .text and .html files.
Rollover of archive filesWhen a rollover archive file is created, a note is added to the log file, so that the listmaster becomes aware of it. In the case of HTML formatting selected, the listmaster may then choose to issue a GET command to receive the fully formatted HTML file by mail, save it to a text file and store it in a folder on a web server, thereby offering a convenient access to the archives. This may be further enhanced by using the new search and indexing tool Apple e.g., a public beta is at www.cybertech.apple.com/Appleeg.html.
Automated web archivesThe entry point folder path is configured within the list-specific settings, in AppleScript using the Web Path property in the Options (List). You may apply the one that is used most often as a general setting, but given lists such as private lists may choose to override with another path using a setting specific to the list. By assigning an invalid path, no web folders or files are created.
If you prefer to use your own html file in the entry point folder, then simply give this file a name other than index.html and make references to this file. It is assumed that your file references the index.html files inside the list subfolders.
Whenever a contribution takes place and the standard archives are updated, so are the web archives plus both the entry point level index.html file and the list subfolder index.html file.
A few changes have been made: all archived files now use hyphens instead of spaces, and some cosmetic changes have been updated for the archive files. It is recommended that prior archives be updated to reflect the new changes.
Specific to individual lists only (the general setting is always the above complete tree), the entry point folder may be configured to be the list folder itself; the upper layer of the subtree (the top-level folder and the top-level index.html) is not created, and the list folder is moved up one level to match that of the entry point folder. In AppleScript, use the Web Archives property (Complete versus Minimal) in the Options (Misc) to configure this selection.
Both Mac-to-HTML and MIME-to-HTML character conversions are automatically applied to both the standard and the fully automated web archives.
Advanced features Multi-domain hostsThe AutoShare Hosts file was added to ease the use of EIMS non-default domains with AutoShare. Assuming that the EIMS default domain is used with the AutoShare bounce address, the domains in the AutoShare Hosts file must match the remaining EIMS domains for list contributions to work properly.
You create the AutoShare Hosts text file in the AutoShare folder inside the System 7 savvy Preferences folder; type in one domain name per line. Verify the list of domains by choosing the AutoShare Analysis menu item from the server and viewing the AutoShare Analysis file; the bounce address is listed first followed by the domains in the hosts file.
Automated bouncesWhen using the automated bounce feature, it is strongly recommended that the bounce account not be identical to the EIMS postmaster account, as mail received by the bounce account is for AutoShare only. And as usual, it is a must that the domain of the bounce address reflect that of the mail server.
Whenever bounce mail arrives, AutoShare's bounce module will process the message file and subsequently send the admin a mail if a list subscriber could not be located. Otherwise the list subscriber is updated in the Bounces On Hold file located in the AutoShare folder inside the System 7 savvy Preferences folder. The subscriber address, the list name, a sent counter (initialized to zero), a received counter (initialized to zero) and an entry created time are the five pieces of information, which are added to each entry in the Bounces On Hold file.
Every so often (using the Bounce Send Mail property in the Options (Misc)), AutoShare sends a mail to each entry in the Bounces On Hold file, and the sent counter is incremented by one. If the subscriber address continues to bounce, the new bounce message causes the received counter of the entry to be incremented by one (additional bounces will not cause the value of the received counter to grow beyond the value of the sent counter, as it should not be a factor how busy the given list is), and once the received counter hits a given threshold (using the Bounce Received Threshold property in the Options (Misc)), the subscriber get unsubscribed, and the entry is removed from the Bounces On Hold file.
If the subscriber address does not continue to bounce, the sent counter continues to grow while the received counter does not, and once the difference of the two values is beyond a given threshold (using the Bounce Sent Threshold property in the Options (Misc)), the entry is considered stable and removed from the Bounces On Hold file.
Entries are also deleted when the current time exceeds the entry created time by a given threshold value (using the Bounce Delete Threshold property in the Options (Misc)). The purging takes place every time test bounces are sent.
The Bounces On Hold file includes entries based on soft bounces only. Hard bounces get unsubscribed immediately per the default behaviour (which includes sending a mail to the listmaster), but may be configured to act as soft bounces. A hard bounce is defined as a sender situation which is not likely to change (such as the sender's address not known), while a soft bounce relates to a temporary situation (e.g. the mail server of the sender may be down due to a network problem). AutoShare does not support many bounce formats at this time, and the 550 code (user unknown) is the only one so far to trigger a hard bounce status.
Miscellaneous features List- and X- RFC fieldsThe List- and X-List- RFC field headers and respective field bodies are:
Other related field headers and respective field bodies are
All of the above fields may optionally and individually be turned on and off on a per-list basis (with the exception of the List-Software field), see the list-specific configuration for AppleScript or the Admin.
Monthly help filesBoth message and digest subscribers receive the monthly help files.
If several lists are to share one monthly help document, you may create aliases reflecting the normal file name format and pointing to the same document.
Subject prefixesIf a + (plus sign) is appended to the prefix, the prefix will appear at the end of the subject instead.
Headers and footersHeaders and footers also appear at the beginning of and end of digests.
For a moderated list, the list contributions forwarded to the list master do not include headers or footers. They will be inserted when the list master posts the contribution to the list.
If several lists are to share one header or footer document, you may create aliases reflecting the normal file name format and pointing to the same document.
Rotating banners Other list related issuesTo reinforce that the unquoted part of a response contribution must be at least a given percentage of the complete message body, change the proper list-specific setting to this percentage. If it does exceed more than the percentage, the message is returned to sender. John Norstad's NewsWatcher applies this restriction to news responses (50% only though), if the news server in question is configured to reject postings which contain more quoted text than new text.
Auto-response documents are located in subfolders inside the Document folder. The subfolder names must correspond to the user names of the AutoShare accounts in EIMS. Inside each subfolder, create a default document called Default. This document is used for senders not specifying a particular string in the subject line. Alternate documents may be created, and the subject line of the sender's e-mail must match one of the names of these documents for it to work.
Auto-response tokensThe contents of an auto-response command document is mostly text that you decide on your own how to reflect the context of the command. Standard auto-response documents also include at least one token line to trigger a given action. Each token pair (a switch and a command) comes with or without any delimiter.
Standard tokens:
/=original = picks up the original messageAuto-response tokens:
/=subject <field> = overrides the RFC Subject field body /=reply-to <field> = inserts an address in the RFC Reply-To field /=poll = activates poll mechanism /=header = picks up the original RFC header only /=rfcfrom = updates envelope recipient to RFC To /=forward <address> = sends copy of original message to addressToken lines are placed as separate lines in documents at appropriate locations depending on the text contents.
Setting up a pollAnyone may vote on a given topic by sending a mail to the Poll address. The topic of the vote is based on the specific subject line. The actual vote of the sender is based on the first line of the body. Whenever a sender tries to vote, the overall vote statistics are returned. If it's the sender's first try, the pool of votes gets updated, and following attempts results in informing the sender of the number of attempts so far.
The poll account may be used to gather all kinds of distribution data based on the key strings (max 20 characters each) in the body. The poll account rejects all subjects which have no corresponding document or uses the Default document. The poll action is triggered by the /=poll token, which should be placed in all documents, also the Default document, in the poll folder. The poll status returned to the sender shows the overall distribution sorted by selection, and graph bars help illustrate the results.
A set of pre-defined key strings may be attached to a poll. When an invalid key string is encountered, AutoShare returns a note to the sender asking for another try. The series of case-insensitive key strings resides in the 'STR ' resource, beginning at 1001 and upwards, of the poll file in question (no user interface has yet been designed).
Filtering can be enabled, so that vacation notices are not returned to for instance list server lists or mailing lists. The filtering applies to From, To, Subject, Reply-To, Sender or any header being one of the five. Inside the Filters folder, documents containing the filter definition lines are named according to the user names of the AutoShare accounts in EIMS.
A particular aspect is the ability to configure a user's filter file, so that any given sender will receive one vacation notice only regardless of how many messages the sender mails to the user on vacation.
In order to reduce of the risk of vacation notices being returned to list server lists, filtering is automatically applied to any messages with a Precedence RFC header field having a field body of bulk, list or junk. In the case of an AutoShare list server, a Precedence RFC header field is added to list contributions.
Incoming UUCP: The EIMS POP account is configured as 'Save as archive' to an inspool folder/user (e.g. 'EIMS HD:Misc:inspool:meh'); this forwarding option satifies Eudora's expections of the mail drop being in the standard Unix mailbox format. The Eudora part (Settings, POP Account, e.g. '!EIMS HD:Misc:inspool:meh') is made possible thru the use of file sharing applied to the EIMS server's harddisk.
Outgoing UUCP: The Eudora part (Settings, SMTP, e.g. '!MEH HD!EIMS HD:Misc:Filed Mail:!meh!0000') is possible thru the use of file sharing to the standard Filed Mail folder. AutoShare automatically acts upon detection of the D./X. UUCP pair of files by converting them into one properly formatted file sent to the EIMS Incoming Mail folder and finishes by deleting the UUCP pair of files.
The contents of the D. file is transferred directly to the data part of the new mail file; the resource part is updated based on the X. file (sender (appends the domain from the Bounce address) as well as (multiple) recipient(s)).
It is recommended that you choose to reduce the file sharing to include the two above folders (the inspool folder and the Filed Mail folder). The mail spooled by Eudora to the Filed Mail folder will stay there for a very brief moment and as such poses no major risk in terms of security. Access to the inspool folder may be adjusted to include the individual user only.
The AppleScript configuration of unique application creator codes is accomplished via the SetKeepUp (adds or deletes an application creator), GetKeepUp (returns the list of active creators) and GetCreatorApp (returns an application name from a creator) commands.
The Admin's Keep Applications Up window makes the configuration particularly easy, in part because the window's Select button allows you to choose an application without knowing the creator in advance.
Suppressing messages using filters General filtersAuto-replies and vacation notices also insert Precedence: bulk. Furthermore, incoming messages with Precedence: junk and Precedence: list also get suppressed.
Specific filtersThe filtering applies to the five fields below in the e-mail header. It also applies to any header being one of the five. Below, the first column indicates which field is to be applied, and the second column lists how to begin a definition line; the rest of this line is a substring aimed at searching in the e-mail header line in question.
From: 'From: '
To: 'To: '
Subject: 'Subject: '
Reply-To: 'Reply-To: '
Sender: 'Sender: '
Any Header: ''
Examples:
Simple filter file:
qualcomm yalevm.cis.yale.edu
The one vacation notice only feature added:
qualcomm yalevm.cis.yale.edu *****When user@domain mails you, it will look like this:
qualcomm yalevm.cis.yale.edu ***** user@domainAnd later:
qualcomm yalevm.cis.yale.edu ***** user@domain user2@domain2Remember to clear and move the file, when you return!
List server requests on listsYou may choose to configure this behaviour differently. The level of suppression of list server commands in subjects and first body line is configured using the Suppress Command property in the AppleScript Misc Options: 1 = always suppressed, 2 = never suppressed, 3 = body only is suppressed.
Loop detection and eliminationFirst of all, it is important to understand the difference between real and RFC header addresses: while the RFC header addresses reside in the e-mail RFC header of the message, the real addresses are found in the resource part of the message file, namely the STR (8192, From) and the STR# (8192, To) resources (in the world of UUCP, the D. file reflects the data part, whereas the X. file reflects the resource part).
Taking advantage of the bounce feature (either On or Empty is an important step towards limiting potential problems with loops (circular references). For all auto-responses and admin log mailings, the STR resource will be updated as coming from the bounce account rather than the auto-response account in question (no change in the e-mail header's From field). This ensures that all messages, which bounce back to your server, are sent to your bounce address (and this one only).
It is recommended that you configure your AutoShare preferences, so that the Admin address is set for a Listmaster account and the Bounce address is set for a dedicated account for error messages. It certainly does not have to be so, but it does serve as an excellent and easy-to-remember solution.
The following examples illustrate various loop situations, in which real addresses tend to differ from RFC header addresses.
Your basic bounce
The list server (in fact any AutoShare account) returns an auto-response to a user, whose mail system is malfunctioning at the time. The message bounces back to the mail system of your list server, but although the list server account is listed in the To field of the e-mail header, the bounce account receives the mail: it is the actual recipient because it was originally the actual sender.
Mail to the same account
You have enabled the vacation notice feature; in terms of EIMS, this means that you have turned on 'Save as files' with the 'Keep' button checked. After having sent the message, your account receives the message; furthermore, the other copy is put in the Filed Mail folder: AutoShare compares the To and From resources, and since they are identical, no vacation notice is triggered. This feature applies mostly, when the bounce feature is not used.
Incoming list mail
An example involving not AutoShare, but EIMS only is messages generated from a mailing list being put into the Filed Mail folder: the To in the e-mail header is the list address, while the To in the resource is the final recipient. While this is not a loop issue per se, it illustrates the difference between the two types of To addresses (this distinction relates to the feeding of the archives thru the use of the 'Save as files' Archives account, which AutoShare benefits from).
NewsWatcher
You have enabled the vacation notice feature and then press Command-Option-L in NewsWatcher, which mails you the news article. The actual sender is you, not the person who posted the article, so there is no problem.
Mail to Cc recipient
This example affects the e-mail header only, but I'll include it anyway. An AutoShare account receives a message, and the address of this account is placed in the Cc field. In this case, AutoShare doesn't use the address in the To field when creating the From address for the auto-response message; instead the newly created From resource is inserted into the From field in the e-mail header.
Remote administration Remote administration by e-mailSetList Options {List: "fun-l", Remote Password: "rosebud"} When applying remote administration by e-mail, let the first body line (if the subject mode for list server requests, then the subject field instead) follow this word pattern:
<password> <command> <e-mail> <list> <rest>for instance
rosebud subscribe a@b fun-l Mr. XCommands supported so far are subscribe (the 5th word is just the rest of the line), unsubscribe (the name is not needed), set (the option is the 5th word), review (use a dummy e-mail address as the 3rd word) and analysis (the password and the command are adequate). The password is case-sensitive, the remaining parameters are not. All of these commands returns an e-mail to the sender with a status; the original command line is included, but the password is replaced by a generic word for safety reasons.
The post command is different from the above commands in several ways. You may use it to post to a list regardless of your client software's configuration, as the e-mail address and user name are picked up from the e-mail and rest tokens respectively. The list token is used to update the recipient, so the contribution gets posted to the list; no e-mail is returned to the sender or the contributor. The body of the contribution message is what follows the initial passworded line (if the subject mode, then put the passworded line in the subject and the subject as the first body line).
The password command may be used to change the password. Enter the new password as the 3rd word. If no list is specified, the request is aimed at the overall password. Both the old and the new passwords are replaced by generic words in the returned message. An e-mail is returned to the sender with a status.
The application and system commands have been added to accomplish remote launching and quitting of applications as well as system restart and shutdown. For either command, you may enter Launch or Quit as the 4th word, and the application command requires the 4 character creator (signature) code of the application in question in the 5th word. The 3rd word is ignored. PS: if you put application creator codes in STR# 206 of your AutoShare Preferences file, AutoShare will launch any of these applications (if not already running) every so often. Keep them up!
Multiple lines using the above format are supported (in the body mode only). AutoShare stops processing the body once there are no more lines beginning with a valid password. While a post line must be the last of one or several passworded lines, it need not be the first.
For safety reasons, I highly recommend the recipient be autoshare@....
The passwords for remote administration by e-mail have been made list-specific in version 1.3, so you need to update all of your passwords to make your configuration current, using the Admin or AppleScript (if you edit your Preferences using a resource editor, please pay close attention).
If AutoShare detects a valid list in 4th word, the list-specific password works as well as the overall password, which works whether or not a valid list has been specified.
It may be added that the somewhat more complex Script By Mail AppleScript sample package offers the alternative of issuing AppleScript commands via e-mail.
Subscriber and administrator web formsUpon arrival, AutoShare detects the Content-type: application/x-www-form-urlencoded RFC field in the message and subsequently turns the mirrored web-originated message files into standard message files (list server requests and remote administration by e-mail respectively). Complete URL decoding is applied to the data received from the web browser.
A subscriber form may use the command, list, name and option tokens as well as the subscribe, unsubscribe, set and review commands.
The remaining commands, new in version 1.4, are: list, index, get, which, release, query, search and help, and new tokens are file (for Get) and string (for Search).
An administrator form may furthermore use the password and email tokens as well as the analysis command (the post, password, application and system commands are not supported in web forms).
New in 2.0 is the comments token, which comes in handy when addressed to auto-response addresses, as the body of the token forms the body of the standard message file.
Mail-back confirmationsTwo new folders are introduced, the Mail Back folder and the Hold Mail folder. The mail-back feature works on a per account basis, so if you would like mail-back enabled for a given account, you re-configure the EIMS Save as files account to point to not the Filed Mail folder, but the Mail Back folder instead. Once the message file appears in the Mail Back folder, AutoShare moves it to the Hold Mail folder and puts a new message file in the Incoming Mail folder, asking the user to confirm by replying to the mail; the first line in the body displays the confirmation key, which is the unique name of the original file generated by EIMS. When the confirmation message file arrives in the Mail Back folder, AutoShare checks the first line in the body, and if it matches the name of a file in the Hold Mail folder, this file is moved into the Filed Mail folder, and the confirmation file is deleted.
The contents of the returned mail-back message to the user will go beyond including just the confirmation key in the first line of the body, if you put a line-based text file entitled Mailback in the Documents/autoshare folder. A blank line and the contents of this file will be added, thereby explaining the user what to do. The /=original and /=subject tokens are supported in the Mailback file.
Deletion of unconfirmed message files takes place automatically. The Hold Mail Check property in the Options (Misc) indicates in minutes (default is 10 minutes) how often AutoShare should check for expired files, and the Hold Mail Expire property indicates in minutes (default is 600 minutes = 10 hours) the duration before expiration takes place from the time the file was created by EIMS.
The AutoShare account is a unique and more complex case, as you may want some commands enabled for mail-back and others disabled. To feature this, a new list-specific Mailback property is introduced in the AppleScript Options (List). If the string is blank, the general setting is looked at, and if the string there is blank too, no mail-back is enabled for the given list. You may add N (None) to the list-specific string to avoid use of the general setting.
The A (All) enables mail-back for all commands for a given list, and if a command does not contain a reference to a list, the general setting is used. Here are the letters for the various commands: S=sub, U=unsub, E=set, Q=query, R=review, I=index, G=get, H=search, W=which, L=list, C=release.
The list-specific string SUQL indicates that the sub, unsub and query commands are mail-back enabled, while others are not; the status of the list command is determined by the general setting, as it is not specific to any given list.
If both the general and list-specific mail-back strings are blank (default), no mail-back takes place for the list server account. It therefore doesn't matter whether the EIMS account points to the Mail Back folder or the Filed Mail folder.
Process extendersWhen AutoShare comes across a hook, AutoShare sends an AppleEvent to the process extender is question, if available. A list of parameters, which the process extender may use, is included in the AppleEvent.
The parameters in the passed list of the AppleEvent are 1. the folder path of the message file, 2. the file name of the message file, 3. the envelope sender of the message file, 4. the envelope recipient of the message file, 5. the RFC From body field, 6. the RFC To body field, 7. the RFC Subject body field, 8. the RFC Date body field, 9. the list name and 10. the contribution alert type.
The contribution alerts are the messages inserted into the beginning of the body, when contributions are not immediately posted for various reasons: 1. not subscribed, 2. announcement list , 3. subscriber not allowed to post, 4. response is smaller than quote, 5. moderated list and 6. too many lines in contribution.
For suggested variable names for the above parameters and contribution alerts, see the Before Processing sample Template process extender.
Process extenders reside at the top level inside the 'Process Extenders' folder, which resides in the same folder as the AutoShare application. Aliases are supported for process extenders, so that these may physically reside elsewhere.
There are several sample process extenders inside each sample type folder. One from each folder may be made active by placing it at the top level inside the 'Process Extenders' folder. All sample files are script applications with the source preserved ("Save As..." Application with both "Stay Open" and "Never Show Startup Screen" enabled).
The following describes the various AutoShare process extenders and also makes references to the sample process extenders. The class and event IDs used are in parenthesises after the process extender name.
Before Processing ('AuBP', 'aUBP')
The Before Processing hook is placed at the very beginning of the processing of a message file in the Filed Mail folder. The execution of the Before Processing process extender is triggered by AutoShare becoming aware that a file resides in the Filed Mail folder.
Within the Before Processing sample folder, the Template process extender illustrates the basic starting-point. The main AppleScript handler merely picks up the call from AutoShare. The purpose of the idle handler is to reduce processing time being allocated to the application when the main handler is not being called.
The List Parameters process extender displays the various parameters being passed from AutoShare. Be sure to have AutoShare running in the background when testing this sample.
The Unconditional Filter process extender intercepts the main AutoShare processing by copying the message file to another folder and completes this task before AutoShare begins its actual processing of the file. If the process extender deletes or moves the file, AutoShare is left with no processing of its own to do.
The Write Log process extender writes a line to the AutoShare log. This sample is particularly interesting, as the sample application calls the very same AutoShare application, which triggered it. AutoShare waiting for the process extender to complete its task causes a Catch-22 situation, because AutoShare does not respond to high-level events during instances of its main processing phase to avoid various high-level event and open file conflicts. The trick is to let the process extender have its calls to AutoShare bypass its requests for high-level event replies; the actual task will be processed instantly though.
After Processing ('AuAP', 'aUAP')
The After Processing samples resemble those of Before Processing. The only difference is the time of being triggered and thereby the message file. This type of process extender is executed just before the final processed file is copied to the Incoming Mail folder.
Subscribe ('AuSU', 'aUSU')
The Subscribe Write Log sample writes a line to the AutoShare log. Be sure not to have your process extender delete, move or otherwise change the message file.
The FileMaker Pro sample creates a new record in a FileMaker Pro database file having a very simple data structure.
The Send Message sample sends a basic welcome message to the new subscriber.
Unsubscribe ('AuUS', 'aUUS')
The Unsubscribe Write Log sample writes a line to the AutoShare log. Be sure not to have your process extender delete, move or otherwise change the message file.
The FileMaker Pro sample looks up the subscriber in the database and sends a message of when the original subscription took place.
After Digest ('AuAD', 'aUAD')
The After Digest Write Log sample writes a list-specific line to the AutoShare log.
Contribution Alert ('AuCA', 'aUCA')
The Contribution Alert Multiple Alerts sample illustrates how to return a list of strings to AutoShare; note the AppleScript return command in particular. The row of lines will override the default text of the given alert message.
You distinguish among the various contribution alert types by using the code of the contribution alert type parameter. The sample shows this in full.
Test Bounce ('AuTB', 'aUTB')
The Test Bounce Write Log sample writes a line to the AutoShare log.
As the parameters reflect the Test Bounce file in the AutoShare Temp folder, you may choose to delete this file and instead send another message to the subscriber in question.
System ('AuSY', 'aUSY')
The System Write Log sample writes a line to the AutoShare log immediately before a System command using remote administration by e-mail takes effect. As the normal purpose of the contribution alert type parameter does not apply, the parameter is instead used to indicate whether the Mac is to be 1. restarted or 2. shut down.
Filter ('AuFI', 'aUFI')
The Filter Write Log sample writes a list-specific line to the AutoShare log. The Copy File sample copies the Filed Mail file to another folder before it is being deleted. The Send Message sample informs the sender that the mail has been filtered.
MIME RFC fieldsWhen the MIME property in the AppleScript Options (Misc) is set to Text Plain (default), the following MIME RFC field is inserted after the Mime-Version field:
Content-Type: text/plainAnd when the property is set to MIME QP or QP Always, the following MIME RFC fields are inserted after the Mime-Version header field:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Mac-to-MIME conversion is applied accordingly in the body of the outgoing message.MIME QP: The MIME property makes a difference for the outgoing message files that are originated by AutoShare and not directly derived from message files arriving in the Filed Mail folder (such as logs, digests and admin notifications). For list contributions and auto-responses, Mac-to-MIME conversion will depend on the MIME RFC fields of the original message as well; the Mac-to-MIME conversion does not take place unless the 'Content-Transfer-Encoding: quoted-printable' field is located (besides the MIME property being set to MIME QP).
QP Always: The MIME Quoted-Printable encoding takes place whether the message file is originated by AutoShare or not.
AutoShare offers MIME Quoted-Printable support for auto-responses with enclosures as well. (The name of the enclosure file will be added to STR# 8193,1 (2-5 are also used) of the outgoing message to insure that boundary lines are inserted correctly at the time of the Mac-to-MIME conversion.) It may be added that if the original mail requesting an auto-response with an enclosure is having a MIME header and no CTE QP header, MIME enclosure handling will be enabled.
Multiple instances of preference setsThe AutoShare Preferences file is designed to run one instance of for instance the list server, and the user interface of the server reflects the actions within one status window.
AutoShare 2.0 offers multiple preference sets, so that you may run multiple instances of for instance the list server, with each instance displayed within its own status window. This comes in handy when configuring EIMS 2.0 to handle multiple domains, as you can also have one list server address per domain.
Non-default preference sets are created in the above AutoShare folder by simply creating empty subfolders having names beginning with the @ sign. When starting up, AutoShare creates respective preference sets within such non-default subfolders.
The configuration of each AutoShare 2.0 preference set must generally correspond to the account configuration of a given EIMS 2.0 domain. It is however possible to arrange for multi-preference sets within a single-domain environment as long as you avoid conflicting user names for the special accounts (autoshare@, poll@, protected@), which is accomplished by adding trailing labels to these user names; use the Listserver Label property in the AppleScript Misc Options to configure the labels.
When using the Listserver Label, it is suggested that no label be configured for the default preference set, so that the list server user name remains autoshare@ for the default preference set. By applying a label of 1 to a non-default preference set, the listserver user name becomes autoshare1@ for this preference set (and so forth).
The user%domain@server configuration in an EIMS multi-domain environment is only necessary when you need to configure a client's POP account to tell the server what domain the account is in.
AutoShare distributes the processing of the preference sets in a round robin fashion. When configuring a given preference set, you must first set it to be the only activated preference set temporarily. You may accomplish this via the Multi-preference entry from the Preferences menu in the AutoShare server user interface by selecting a given preference set. Once the configuration has been completed, you may return to normal processing by selecting All via the same Multi-preference entry.
Temporarily activating a given preference set is also supported by the AppleScript commands entitled SetPreference (which activates a given preference set: <name>, Default or All), GetPreference (which returns the current preference set selection) and GetPreferences (which lists the preference set names).
Folders and aliasesThe AutoShare folder in the System Preferences folder may figure as a folder alias. The alias to the actual folder located elsewhere is resolved when AutoShare starts up.
AutoShare Temp folder Processing modesThe normal processing mode may be manually disabled and enabled, either via the toggling disable/enable processing menu item in the server Preferences menu or via the AppleScript NonProcessing property in the SetStat command. If you accidently leave AutoShare in the non-processing mode, there is no reason to worry, as AutoShare will check every so often (defaults to 60 minutes) to see if it is okay to re-enter the normal processing mode.
Locking filesIt may be manually disabled and enabled, either via the toggling disable/enable locking menu item in the server Preferences menu or via the AppleScript LockingFiles property in the SetStat command. If you accidently leave AutoShare in the locked mode, AutoShare will check every so often (defaults to 60 minutes) to re-enter the normal unlocked mode.
Out of memory and low on disk spaceSituations relating to AutoShare being low on memory are often temporary, so one reminder only per incident will be issued. Future transactions will be processed in a normal fashion, although some specific transactions may cause history to repeat itself, at which times further reminders will be issued.
When a disk is close to being full, the situation is not likely to change much by itself. Both periodical and pre-processing checks applied to all involved volumes will be performed based on a worst-case scenario, and when the threshold has been hit, the processing of the current task will be completed if possible, the reminders will be issued, and AutoShare enters the non-processing mode. Once the situation has been resolved, AutoShare resumes normal processing.
When AutoShare gets low on disk space, it no longer shut downs, but instead moves into the non-processing mode. Messages are mailed to the listmaster every hour to inform of the low disk space situation. When adequate disk space has been restored (checking for this every so many minutes (defaults to 60); AppleScript, see the Processing property in Misc Options; the Admin, see the More Misc window), AutoShare returns to normal processing.
Drag and drop onto AutoShareThe terms default and override are used often in this section. The generic meaning of these two words is applied to the list-specific configuration of AutoShare to indicate, that if you don't go out of your way to configure a given setting for a list, the respective general setting will be used instead. Many lists frequently share the same settings, which conveniently may be configured on the general level (a list-specific setting defaults to a general setting), whereas truly list-specific settings may be configured on a list level (a list-specific setting overrides a general setting). As a rule, strings being blank and numeric values of -1 are most often the override values indicating default.
The AutoShare Preferences file resides in the AutoShare folder within the System 7 Preferences folder and is created automatically by AutoShare, when starting up.
List-specific settings
AutoShare also initializes the list-specific settings in this file by creating standard default values, when starting up. The list-specific configuration is stored in STR# 1001 and upwards, one STR# per list. Index numbers for fields and description of values within these are:
General list settingsSTR# 1000 holds the general configuration for lists and uses the layout of fields and values for the list-specific settings. You probably have to update the configuration for only some of the fields for a given list: if the fields marked in the general configuration contain the same data as you would like to apply to the list, they are considered default values for the list if you leave the respective list-specific fields alone.
Miscellaneous settingsSome server configuration not relating to lists is kept in STR# 201 (string values default to blank):
All of the configuration data may be viewed in the AutoShare Analysis file. Or perhaps best is the user interface of the AutoShare Admin, which communicates with AutoShare via scripting.
The development environment of AutoShare does not rely on a framework such as PowerPlant or MacApp. The PowerPC native version is compiled and linked directly from sources to application and does not use a PowerPC conversion tool such as MacApp2PPC.
When AutoShare 1.0 was released, it was the first 68K list server for the Mac, and with the release of version 1.1, AutoShare was also the first true PPC native list server for the Mac.